The idea previously was that a worker thread can't leave the
scheduler role until the scheduler is stopped or there are tasks
to do.

But actually nothing prevents from leaving the scheduler, entering
it again, and then sleeping on waiting for tasks.

It allows to simplify the state machine of the scheduler a bit.
Gives a guarantee that the scheduler-role will consume the front
signal only once per scheduling iteration.

This guarantee in turn is going to be quite handy in the future
potential API improvement for making it possible to run the
scheduler in user's threads.

Part of #40

Atomic "and" + "or" are going to be quite handy in the next
commits. They could be implemented manually, but it is much easier
to just take the STL version.

Needed for #40

The new class is a special type of mutex which allows to take the
lock, go to sleep on some arbitrary condition (a condition
variable, a epoll_wait() call, a Signal.ReceiveBlocking(), or
something similar), and then get woken up when other threads want
to take the ownership.

This is an abstraction of the TaskScheduler's usecase. The
scheduler workers are going to be taking the lock and sleeping
when have to wait for new tasks or for a deadline. And other
threads would forcefully take the ownership when need to do some
maintenance work like stop/start of the scheduler or getting
something out of the scheduler-role context.

Currently there isn't much of the second type of work, but this
will change in scope of #40.

Part of #40